IBIS Macromodel Task Group

Meeting date: 31 July 2018

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
                              Stephen Slater
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
SiSoft:                     * Walter Katz
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:
- Arpad noted that he had removed the "Pending BIRDs, expected to be rejected"
  list from the agenda email.  At the last IBIS Open Forum meeting, the 4 BIRDs
  on that list were all officially rejected.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the July 24
meeting.  Walter moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

Upgrading the input thresholds/measurement info to include eye diagram specs:

Walter shared and reviewed his "DDR4/DDR5 discussions" email, which was sent to
the ATM group after the last meeting.  He noted that he intended the email as a
summary of the state of discussions on this topic and the "single ended
applications of AMI" topic.  Walter noted 4 primary issues:

1.  Thresholds - Walter noted that this would be resolved with the new keyword
    proposal discussed at the previous meeting:
        [Standard] <standard> <bus>   (or something similar).
        
Arpad said he agreed in general, but that details might change.  Walter agreed
and said this was intended as a high-level overview.

2.  Clock Forwarding - Walter suggested that one solution was to use the
    existing clock_times (pointer) argument in the AMI_GetWave() function
    signature for passing clock waveforms into the .dll as well as receiving
    clock ticks back from it.
    
Walter noted that it's not difficult to pass DQS clock waveforms into the Rx
GetWave().  He suggested the hard part for IBIS will be documenting how the EDA
tool should generate the clock waveforms and how the .dll will consume them.
Walter suggested we table this particular issue until we take up a BIRD to deal
with the details.

Arpad noted that the clock ticks passed back from the .dll are used to assemble
the eye diagram.  He asked if we would need to send the clock waveforms into
the .dll, or if the EDA tool could just process them directly and apply the
information.  Walter/Ambrish noted the Rx might have a DFE.  Walter noted that
it might not be clear how the phase between clock and data would be determined
inside the model.  In DDR4 there is a training process to determine that phase.
Arpad asked how that clock waveform would be passed in to the .dll.  Ambrish
said it could be passed in using the same format that the data waveform uses
(data waveform is passed in using the "wave" pointer argument).

Walter noted that we would want this to work for DDR5 writes, which are
controlled by the JEDEC DDR5 standard.  But, we probably also want to run
simulations for DDR5 reads, and there is no specification for what the
controller does in that case.  Walter noted his conversation with Steve Parker
(see notes for previous meeting), and noted that there might buses other than
DDR5 for which this would be applicable.  He had suggested that Steve could
write a BIRD himself or ask IBIS to add this feature.  Walter said we needed
someone to take up a BIRD.  Ambrish noted that he had proposed writing a BIRD to
address clock forwarding and the floating Vref, and he said he would check back
with his co-workers.

3.  Floating Vref - Walter noted that IBIS's existing Vinl and Vinh might not be
    very meaningful for this since they are absolute quantities.  Walter noted
    that the standard would define this, so the [Standard] keyword would address
    this issue.  The standard would say that it's a floating Vref, and the EDA
    tool would adjust the offset accordingly to find the VREFDQ that yields the
    best eye opening.  One metric is the widest eye; another is the largest
    eye mask margins.
    
Randy noted that it might be useful to have the Vref value that is calculated by
the tool be passed into the AMI model.  Walter agreed, and noted that since the
AMI model uses an impulse response it knows nothing about the DC level.  Walter
said it might be useful to add a new Reserved Parameter for that purpose.  Randy
noted that this might be part of the BIRD Ambrish/Walter had just discussed.

Fangyi asked how Vref would be used if it were passed into the model.  Randy
said you could potentially use it to look up different tables describing CTLE
behavior.  There are certain things being modeled that could be sensitive to the
Vref level.  Arpad asked if Vref would be provided once at the beginning of the
simulation, or if it needed to be continuously updated.  Randy noted that Vref
is generated inside the DRAM, but they model it by having the system specify
what that Vref level is and assume that's what's being used in the VRAM.  Arpad
asked if it would be generated once or continuously updated based on noise,
temp, etc.  Walter said that it would be calculated once, and it's typically the
midpoint between the initial and final values of the step response (which is the
same for a rising or falling step response).

Fangyi noted that this raised an interesting question.  What is the input signal
to the Rx GetWave() function in this scenario?  Is it differential or single
ended?  Walter noted that this was a good question, and the tool could make
the waveform input to the Rx GetWave() either way.  The waveform could be
centered about Vref, or it could be centered about 0 with the Vref offset kept
track of separately.  Ambrish asked if it mattered to the .dll.  Fangyi said
yes, that DFE would care about the threshold.  Walter noted that removing the
Vref (waveform centered about zero), allowed the AMI block to operate as
differential and the bias could be added back later.  Ambrish noted that the
threshold could be calculated dynamically.  Fangyi agreed, and said this was
why he had asked his first question about what the model would use for the Vref
(how it would be used if Vref were passed in via a Reserved parameter).  If we
had a single ended signal with a DC bias, then perhaps the model could use a
Vref passed in, or internally generate the Vref if it were passed the single
ended waveform including the bias.

Fangyi noted that we could even change the specification for the input to the Tx
GetWave(), so it would no longer have to be differential.  Walter agreed that
there were many possible approaches.  Walter noted that he thought it was not
necessary to make many changes, and that we could say that for the AMI modeling
and processing you're centered about zero and handle the bias separately.

Fangyi said he thought it might be better if the waveform passed to GetWave()
represented the actual signal as much as possible.  If the signal has a DC
bias, then the waveform should probably have that bias.  Fangyi said that this
would likely make life easier for the model makers.  They likely have a block
that detects the threshold voltage, and they could just convert that block into
an AMI model.  Otherwise, if we gave them a differential signal, the model
maker would have to remove that threshold block when they created their model.
Walter noted that these were all good points for a detailed discussion.

Walter noted that the bias issue is simple to handle.
  - We could strip out the bias and leave the AMI processing with zero-centered
    waveforms.  OR
  - We could handle it with a Vref Reserved parameter and pass the single-ended
    waveform containing the bias to the GetWave().  The model could then use
    the Vref Reserved parameter or compute the bias itself.

4. Asymmetric rise/fall - Independent of how we handle the bias, Walter posed
   the question, "How do we generate the input to the Rx GetWave()?"
   - We know there is rising/falling asymmetry for DDR5.
   - Is it possible the effect is small enough to be ignored?
     - Here we will assume the differences are important.
   - Can this be handled by the EDA tool without changing the AMI signatures?
     - Ambrish/Walter say it can be done.
     - Keysight says the current flows are broken.
   - Both statements are probably right.
   - Do we change the API or the flows?
   - Statistical flow currently says "one" IR represents the systems.
   - Time Domain flow has the same issue.  It says convolve with "the" IR of the
     channel, which doesn't make sense if you have two impulse responses.

Walter noted that we have to assume the EDA vendors have implemented GetWave()
flows for DDR5.  We have to assume they are all currently different.  If we all
described the way we create that input to GetWave(), then we could see if we
agree enough to write a BIRD.  But, if one disagrees then they wouldn't be happy 
with the BIRD.

Fangyi said the question went beyond whether we change AMI function signatures
or the flows.  The question is more fundamental.  Are the basic assumptions of
AMI valid?  AMI assumes the channel is LTI so we can partition the channel and
do convolution.  The fact that the rising/falling edges have asymmetry indicates
that this system is not LTI.  The system response depends on the signal if
rising edges and falling edges have different system responses.

Walter agreed that it's not strictly LTI.  The interconnects are certainly LTI,
but the driver is not because of the rise/fall asymmetry.  Can we somehow meld
the rising and falling step responses into a single impulse response?  If you
just use the rising step response (typically slower edge rate) you get an answer
that is too pessimistic.  If you just use the falling step response you get an
answer that is too optimistic.  If you "average" them out, you get an answer
that does a decent job predicting the performance of the channel.  Radek noted
that because of the non-linearities even the rising step response you compute
may not reflect what's happening for a different signal.

Ambrish said that the solution they implemented was transparent to both the user
and the AMI model.  So, they didn't think footprint or flow changes were needed.
The flows are just sample flows for differential SerDes.  It's okay to have a
different flow that integrates the rise/fall asymmetry.

Fangyi said the validity of the entire AMI modeling technique is questionable
for this application.  Walter said if we think primarily about DDR5 writes,
where we know the Rx has DFE (the JEDEC standard doesn't really define what's
in the controller for equalization, so we don't what the Tx eq is for writes or
the Rx eq is for reads), we can ask the question, "Can we get an answer from AMI
simulation that is good enough to make engineering decisions?".  Can AMI
correlate well enough with measurements or full transistor simulations?  He and
Ambrish believe that you can get there with AMI modeling techniques.  There are
ways to do it with Init() flows that give you reasonable answers, and there are
ways to do it with GetWave() that produce extremely good waveforms for Rx
GetWave() that capture the rising/falling asymmetry and downstream reflection
effects.  No modeling is perfect, but can the existing AMI footprint and
methodology give engineers useful tools?  Ambrish and Walter say yes.  Fangyi
and Radek aren't so sure.

Walter suggested we might consider having a multi-vendor panel discussion at
DesignCon.  Others noted their hope that we would make progress long before then.

Arpad asked if we could consider SSO effects too, if we were going to consider
modifying AMI.  Walter noted there are two parts to SSO, crosstalk and power
delivery effects.  AMI can handle crosstalk, and currently EDA tools could model
some power effects but it's totally incompatible with AMI itself.

- Mike L.: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 07 August 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
